REMARKS/ARGUMENTS 



Remarks concerning amendments to specification 

The background section of the specification has been amended to include additional background 
material describing in more detail certain aspects of the standard TCP protocol. 

Response to rejections 

Claims 1-19 were rejected under 35 USC 1 12, first paragraph, because it is not clear to the 
Office from the specification how to use the invention. The Applicant maintains, however, that 
the use of the present invention is clearly described and specified in a manner that would be 
readily understood by anyone skilled in the art of internet protocols. 

In particular, any skilled internet engineer would be familiar with the fact that an internet packet 
sent from a transmitter may be split by intermediate network devices during transit into multiple 
packets prior to arriving at a receiver. In other words, the packets sent do not necessarily 
correspond to the packets received. To accommodate for this packet splitting, the ACK signals 
used in the TCP protocol refer to octet segment numbers received rather than packet identifiers. 
Thus, if a packet is split up during transit, a receiver may send to a transmitter multiple ACKs 
corresponding to the various split packets that were received (see figure below). Consequently, 
in accordance with standard TCP protocol, the transmitter properly interprets these non- 
duplicate ACKs as representing acknowledgement of the distinct packets that arrived at 
the receiver, regardless of whether or not their sequence numbers correspond to the same packet 
sent from the transmitter. 
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Furthermore, any skilled internet engineer would be familiar with various well-known RFC 
documents published by the Internet Engineering Task Force (http://www.ietf.org/), such as RFC 
793 which specifies the TCP protocol and RFC 2001 which describes TCP Tahoe (the most 
popular TCP flow control specification). RFC 793 explicitly declares fragmented ACKs as new 
ACKs that the transmitter must process. RFC 2001 declares the use of new ACKs for the 
purpose of triggering the rate recovery mechanism: 

"Congestion avoidance and slow start require that two variables be maintained for each 
connection: a congestion window, cwnd, and a slow start threshold size, ssthresh. The 
combined algorithm operates as follows: 

1. Initialization for a given connection sets cwnd to one segment and ssthresh to 65535 
bytes. 

2. The TCP output routine never sends more than the minimum of cwnd and the 
receiver's advertised window. 

3. When congestion occurs (indicated by a timeout or the reception of duplicate ACKs), 
one-half of the current window size (the minimum of cwnd and the receiver's advertised 
window, but at least two segments) is saved in ssthresh. Additionally, if the congestion is 
indicated by a timeout, cwnd is set to one segment (i.e., slow start). 

4. When new data is acknowledged by the other end, increase cwnd, but the way it 
increases depends on whether TCP is performing slow start or congestion avoidance." 

In view of the above, the teaching of the present invention is clear and unambiguous. In 
particular, claim 1 recites a second host (i.e., receiver) "sending a plurality of non-duplicate 
acknowledgements of a single packet whenever a packet is received after an out-of-order packet 
is received". Because the method is implemented at the receiver, the recited "single packet" 
clearly and necessarily refers to a single packet that arrived at the receiver, and not to a packet 
sent from the transmitter, as would be evident to any internet engineer. In addition, the recited 
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"non-duplicate acknowledgements" clearly refer to acknowledgements of contents of the single 
packet received at the receiver. Since the TCP protocol clearly allows acknowledgements 
with intermediate but distinct octet sequence numbers as new acknowledgements, these 
non-duplicate acknowledgements are interpreted by the transmitter as valid non-duplicate 
acknowledgements of separate packets, and subsequent action of increasing window size is 
taken on them as if they were acknowledgements of different packets, in accordance with 
standard TCP, as would be understood by any skilled internet engineer. 

The Applicant has amended to specification to facilitate understanding of certain aspects of the 
standard TCP protocol as it is commonly implemented and understood, e.g., as described in 
public internet specification documents RFC 793, RFC 2001, and RFC 2581 published by the 
Internet Engineering Task Force (http://www.ietf.org/). All the material added to the 
specification in this amendment is long-standing public knowledge in the internet community, is 
well-known to all internet engineers, and does not add any new matter to the application. 

Applicant respectfully requests that a timely Notice of Allowance be issued in this case. 
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